Differently from a generic information retrieval system, a system that exploits information from the documents' domain specific language (DSL) metamodel has some peculiar dimensions to specify in its design \cite{Bozzon:2010:SRW:1884110.1884112}:
\begin{itemize}
 \item \emph{Segmentation granularity}: this is the atomic unit that the IR system retrieves. The granularity can be at different model levels: entire project, subproject or metamodel concept.
 \item \emph{Elements to extract from the models}: only the most significant elements are extracted from the segments. These elements are the ones that will be processed by the Content Processing Pipeline and searchable through the index where they are stored.
 \item \emph{Index structure}: the index contains the information extracted from segments in the form of \emph{documents}. Typically each segment extracted from the project models is a different document into the index. The index type can be flat, weighted, multi-field or structured.
 \item \emph{Query type and result visualization issues}: these parts involve  many kinds of design choices, including the query type (keyword-based, document-based, search by example, faceted search) and visualization (snippet visualization, highlighting).
\end{itemize}

\noindent In the following, we explain each design dimension with further details and we specify to which phase of the abstract solution presented in Section \ref{abstract-solution} the design dimension refers.

\paragraph{Segmentation granularity}
This is a very important dimension which defines the atomic unit that the IR system can process, index and search. The granularity is the level at which the entire project is sliced. This means that the granularity segment corresponds to the size of the documents that user searches through a query and that is present in the ranked list returned by the IR system. The dimension of segmentation granularity affects the whole Content Processing pipeline (Section \ref{abstract-solution}) and, in particular, the Segmentation phase, where the actual splitting is performed. An indexable document can correspond to:
\begin{itemize}
 \item \emph{Entire project}: in this case, no actual segmentation is performed, an indexable document is equivalent to a project into the repository and the query result is a ranked list of projects.
% Di questo (subproject) NON sono sicuro
 \item \emph{Subproject}: an indexable document corresponds to a smaller piece of the original entire project model. The entire project models have to be split in smaller parts according to some criteria. 
 \item \emph{Metamodel concept}: it's the segment granularity at the lowest level of slicing; in this case an indexable document corresponds to a metamodel concept. A \emph{metamodel concept} is an element of the metamodel of the language used to express the project models. For example, a metamodel concept for WebML is ``area'', while for UML is ``class''. Every indexable document corresponds to a concept in the metamodel. Every concept contains a reference to its container element and possibly references to other related concepts. The query result is a ranked list of model concepts, possibly of different types. The user can browse their related concepts.
\end{itemize}

\paragraph{Elements to extract from the models}
The segments from the project models can hold different information, thus some of them could be not useful for the purposes of the IR system. Therefore, the designer studies the metamodel elements, their semantics and significance. After that, he chooses the most suitable elements that will be indexed. The actual extraction of the elements that are suitable for indexation is performed in the Segment Analysis phase (Section \ref{abstract-solution}).

For example, if we're developing a text-based search engine that searches and retrieves models conforming to a UML class diagram metamodel, the models may include many information, such as the visibility of the class members. In this phase, the designer may notice that this information is not useful for searching purposes and so he may decide to not include it into the index.

\paragraph{Index structure}
The index structure defines the way the segments and their related information are represented as \emph{documents} into the index. Designing the index structure resembles the design of a database schema. An index structure consists of one or more fields. The division of the index into fields allows the user to match different parts of the query string to specific fields of the index. These types of queries are called multi-field query. The design dimensions that refer to the index structure affect the Indexing phase of the approach presented in Section \ref{abstract-solution}.

The following list shows the options that can be used to design the index:
\begin{itemize}
 \item \emph{Flat}: this is the baseline for a model-driven IR system. The index structure is single-fielded and stores bags of words in an undifferentiated way. All the elements extracted from the models are put in the only present field without taking into account the metamodel concept of that element, the relationships with other elements or its structure.
 \item \emph{Weighted}: the index is still single-fielded but this time the terms are weighted according to their concept. The ranking algorithm will give an higher significance to terms occurring in more important concepts. Here we use the words ``weight'' and ``payload'' as synonyms.  This kind of solution is the same one adopted in some of the experiments we have implemented that are discussed in Section \ref{uml-case} and Section \ref{webml-case}.
 \item \emph{Multi-field}: the index has several fields which contain terms belonging to different concepts. The index is said to be multi-field and each field is searchable separately (multi-field query). One can also decide to assign a specific weight to a field during the Searching process. The ranking algorithm gives different importance to matches based on the field where they occur according to the specific similarity measure adopted by the system. Notice that this kind of weighting is significantly different from the terms' payload discussed in section \ref{uml-case} and \ref{webml-case}. This solution can also be combined with the weighted approach producing a multi-field weighted index.
 \item \emph{Structured}: the structured approach represents the model in a way reflecting the hierarchies, associations and relationships among concepts. The index model can be semi-structured (XML-based) or structured (e.g. the catalog of a relational database). In this case the query processing can use a structured query language (e.g., SQL) coupled with functions for string matching.
\end{itemize}

\paragraph{Query type and result visualization issues}
In the context of model searching, an IR system can offer different methods for query submission and result visualization options. Regarding the query submission modalities, in the most basic case, the user can submit a \emph{keyword-based query}, providing a set of keywords that the system matches to the indexed documents. The system then returns a ranked list of documents according to their relevance with respect to the query. In the \emph{document-based search}, the user provides a document (the representation of a project) as query. The system analyzes the document, extracts the relevant keywords and submits them as the actual query. In the \emph{search by example} approach, the user can provide a model as a query. The model is first analyzed in the same way as the project in the data source repository by the Processing Pipeline. This analysis produces a document to be used as a query. Here for document we mean any representation of the model used for matching, which can be a bag of words, a feature vector in the Vector Space Model or a graph in a graph-based searching approach. In the \emph{faceted search} the user explores the repository using \emph{facets}, that typically correspond to the possible values of an indexed field. Another possibility is to submit an initial query first, and then filter the results using faceted navigation. The application of facets refines the results obtained by the query.

Regarding the presentation of query results, there are several ways to improve the user experience when browsing such list. For example, each item in the result set can be associated with an informative visualization of the result (\emph{snippet visualization}). This informative visualization can be a transcription of indexed documents in a flattened textual form or a graphical representation (e.g., for a UML model, one can decide to plot the UML diagram snippet of the returned result). Another way of improving the user experience is by \emph{highlighting} the matched terms into the textual transcription of the returned documents.
